From RM-ODP to the Formal Behavior Representation

In this work we consider the behavioral aspects of system modeling. In order to specify the behavior of a system, many different notations can be used. Quite often different terms in these notations are related with to same element in a system implementation. In order to relate these terms and guarantee the consistency between different notations some standard can be used. In this work we show how the Reference Model for Open Distributed Processing (RM-ODP) can be used for the purpose of the mapping of terms from different behavioral notations. In particular, we show the correspondence between terms in UML activity diagrams, UML state diagrams and Finite State Automata by means of relating them with RM-ODP terms. This allows us to consider RM-ODP as a possible meta-model for behavior specifications written in UML, which help to insure the consistency of UML models

Context Based Reasoning in Business Process Models

Modeling approaches often are not adapted to human reasoning: models are ambiguous and imprecise. A same model element may have multiple meanings in different functional roles of a system. Existing modeling approaches do not relate explicitly these functional roles with model elements. A principle that can solve this problem is that model elements should be defined in a context. We believe that the explicit modeling of context is especially useful in Business Process Modeling (BPM) where the meaning of any model element should be defined precisely. The contribution of our work is at the contextaware modeling framework for BPM. We model a system as the composition of small roles, where each role of a system is defined in its own context

A Synthesis of Business Role Models

Modern Information and Communication Technology open a door for innovations that can improve the functioning of companies. Many innovations can come from the analysis of business processes. Today modeling is widely used for the analysis of business processes. In these work we propose a process modeling technique based on role modeling. To specify a process where one business object may play several roles, a synthesis operation (the composition of two base roles in a third role) has to be specified. All role-based techniques have difficulties specifying role synthesis: synthesis is never specified without the description of actual messages passing between business roles. Such implementation details complicate the understanding of the model and semantics of synthesis become implicit. To specify a business process of a complex system at a higher level of abstraction requires the proper understanding of relationships between roles, when they are put together in one common context. In this paper we define the concept of synthesis constraints that shows relations between roles. Using synthesis constraints allows a business modeler to make explicit his decisions about how the synthesis is done in an abstract and implementation independent way. This approach can be used for building a BPR case tool that enables the discovery of new business processes by means of different disassembling and assembling of roles

Precise Graphical Representation of Roles in Requirements Engineering

Modeling complex systems can not be done without considering a system from multiple views. Using multiple views improves model understandability. However the analysis of models that integrate multiple views is difficult. In many cases a model can be evaluated only after its implementation. In our work we describe a visual modeling framework that allows for the evaluation of multiview models. We give an overview of our framework using a small case study of a Simple Music Management System. For each view in our framework we specify a separate role of the system. The whole system is specified as a composition of smaller roles. Each role, as well as the whole model of a system, can be evaluated by means of the analysis of possible instance diagrams (examples) that can be generated automatically. Instance diagrams are generated based on the formalization of visual models using the Alloy modeling language

The Role of Synthesis Constraints in Role Modeling

To reuse existing specifications and increase the speed of development, modern development methods widely use design patterns and collaborations. Both, design patterns and collaborations, use the concept of role as a basic modeling concept. To specify models where one object may play several roles, a synthesis operation (the composition of two base roles in a third role) has to be specified. All role-based approaches have difficulties specifying role synthesis. As a consequence, synthesis is never specified without the description of the actual implementation of the synthesis. To specify synthesis at a higher level of abstraction, independent of implementation, requires the proper understanding of relationships between roles, when they are put together in one common context. In this paper we define the concept of synthesis constraints that shows relations between roles. We show how synthesis constraints can be used to specify the role synthesis operation. Using synthesis constraints allows a designer to make explicit his decisions about how the synthesis is done in an abstract and implementation independent way. Specifying synthesis with synthesis constraints is a powerful technique that can be used in many different domains, especially in business engineering. The use of roles allows a developer to specify separately certain concerns of a business system. This enables the discovery of new business models for a business system by means of different disassembling and assembling of roles

Systemic classification of concern-based design methods in the context of enterprise architecture

Enterprise Architecture (EA) is a relatively new domain that is rapidly developing. "The primary reason for developing EA is to support business by providing the fundamental technology and process structure for an IT strategy” [TOGAF]. EA models have to model enterprises facets that span from marketing to IT. As a result, EA models tend to become large. Large EA models create a problem for model management. Concern-based design methods (CBDMs) aim to solve this problem by considering EA models as a composition of smaller, manageable parts—concerns. There are dozens of different CBDMs that can be used in the context of EA: from very generic methods to specific methods for business modeling or IT implementations. This variety of methods can cause two problems for those who develop and use innovative CBDMs in the field of Enterprise Architecture (EA). The first problem is to choose specific CBDMs that can be used in a given EA methodology: this is a problem for researchers who develop their own EA methodology. The second problem is to find similar methods (with the same problem domain or with similar frameworks) in order to make a comparative analysis with these methods: this is a problem of researchers who develop their own CBDMs related to a specific problem domain in EA (such as business process modeling or aspect oriented programming). We aim to address both of these problems by means of a definition of generic Requirements for CBDMs based on the system inquiry. We use these requirements to classify twenty CBDMs in the context of EA. We conclude with a short discussion about trends that we have observed in the field of concern-based design and modelin

Systemic Classification of Concern-Based Design Methods in the Context of Enterprise Architecture

Enterprise Architecture (EA) is a relatively new domain that is rapidly developing. The primary reason for developing EA is to support business by providing the fundamental technology and process structure for an IT strategy [TOGAF]. EA models have to model enterprises facets that span from marketing to IT. As a result, EA models tend to become large. Large EA models create a problem for model management. Concern-based design methods (CBDMs) aim to solve this problem by considering EA models as a composition of smaller, manageable parts concerns. There are dozens of different CBDMs that can be used in the context of EA: from very generic methods to specific methods for business modeling or IT implementations. This variety of methods can cause two problems for those who develop and use innovative CBDMs in the field of Enterprise Architecture (EA). The first problem is to choose specific CBDMs that can be used in a given EA methodology: this is a problem for researchers who develop their own EA methodology. The second problem is to find similar methods (with the same problem domain or with similar frameworks) in order to make a comparative analysis with these methods: this is a problem of researchers who develop their own CBDMs related to a specific problem domain in EA (such as business process modeling or aspect oriented programming). We aim to address both of these problems by means of a definition of generic Requirements for CBDMs based on the system inquiry. We use these requirements to classify twenty CBDMs in the context of EA. We conclude with a short discussion about trends that we have observed in the field of concern-based design and modeling

Role Composition in Requirements Engineering:the Method and Prototyping Tool

Using multiple contexts improves model understandability and contributes to solving a scalability problem. In our work, we introduce a modeling method called Systemic Enterprise Architecture Methodology (SEAM) that considers systems to be designed in different contexts. For each context a designer specifies base roles and then composes them into the whole model of the system. The analysis of models that integrate multiple roles, however, is difficult. In many cases models can be evaluated only after their implementation. Building a rapid prototype for the system, composed of multiple roles, can be helpful for evaluating its key features before its implementation. We understand rapid prototyping to be an early development phase for building small-scale implementations (prototypes). In this work, we present a tool that supports role composition. It is based on two programming techniques: Subject Oriented Programming (SOP) and Aspect Oriented Programming (AOP)

Practical Foundations of Business and System Specifications

In this work we consider the behavioral aspects of system modeling. In order to specify the behavior of a system, many different notations can be used. Quite often, different terms in these notations are related to the same element in a system implementation. In order to relate these terms and guarantee the consistency between different notations, a standard framework should be used. In this work we show how the Reference Model for Open Distributed Processing (RM-ODP) can be used for the purpose of the mapping of terms from different behavioral notations. RM-ODP behavior models are based on the concept of Time Specific Action. Time Specific Actions represent directly things that happen in the Universe of Discourse with explicit reference to time. However the explicit reference to time leads to a considerable loss of abstractness. To elevate the level of abstraction we have considered Time Abstracted RM-ODP models where concrete time information is omitted. We used Time Abstracted RM-ODP models to show the correspondence between terms in UML Activity Diagrams, UML Statechart Diagrams and CCS process algebra by means of relating them with RM-ODP terms. This allows us to consider RM-ODP as a possible meta-model for behavior specifications written in UML. It can help to insure the consistency of UML models